An operating system (OS) is a collection of programs that provide an interface to and a set of abstractions of system resources to higher-level programs called applications. The OS enables the applications to access a computer's hardware, such as its processor, memory, and disks, in a uniform and controlled manner. The OS includes programs called “drivers” that control access by the applications to certain computer hardware components, called devices, which can be added to and removed from the computer. A driver understands the low-level hardware details of a specific device (or a group of similar devices) so that it can communicate with the device(s).
A given device can have one or more hardware IDs. Many are based on a vendor ID and a product ID, and some are based instead or additionally on other IDs such as the class ID or the revision ID. When a device is added to a computer, the OS queries the properties of the device to assemble a list of hardware and compatible IDs for the device and the instance ID of the device and consults a local database, such as the registry in Microsoft Windows® OS, to check whether the device has been detected before and whether a driver was previously mapped to that particular device. If no mapping exists for the device, the OS uses the list of hardware and compatible IDs for the device to try to locate and select a driver to use for the device. Multiple drivers may be available, so a ranking scheme is used to pick the best driver. This process for selecting the best driver is carried out by searching through information files of drivers, commonly known as INF files, to find drivers that support the hardware and compatible IDs for the device and then selecting the driver based on a combination of factors: (1) the version and release date of the driver; (2) whether the driver has been certified; and (3) how closely the hardware ID supported by the driver matches the hardware ID(s) of the device. However, if no driver is available, the OS asks the user to insert a CD or floppy disk containing the driver. Newer versions of the OS will also use the Internet to check for additional drivers before the user is prompted.
The user may also select a particular driver for a device through an OS interface that displays a ranked list of compatible drivers. In preparing the interface, the OS enumerates hardware and compatible IDs of the device and searches through information files of drivers to find drivers that support the enumerated hardware and compatible IDs. After the list of drivers has been assembled, the OS ranks the drivers based on a variety of factors including: (1) the version and release date of the driver; (2) whether the driver has been certified; and (3) how closely the hardware ID supported by the driver matches hardware ID of the device. It should be recognized that the OS limits the selection of a driver for a particular device, whether the selection is performed automatically by the OS or by the user from a list generated by the OS, to ones that claim to support the device, so as to prevent crashes or other types of issues from occurring.
In some situations, it may be desirable to substitute a different driver for a device for which an existing driver has already been loaded by the OS. An application may want this feature to access the device in new ways not previously permitted by the existing driver. The application can also gain exclusive access to the device if the new driver exports a set of program calls known only to that application. This would prevent other applications from even knowing that the device exists.
One example application for which driver substitution is useful is a virtual machine monitor (VMM), which provides a supporting interface for a virtual machine (VM), in situations where the VM wants exclusive access to a physical USB device. To support the VM's access to the physical USB device, a special USB driver called a “generic” or “pass-through” driver needs to be loaded for the VMM. Unfortunately, even before the VMM began running, the OS may have loaded a different driver for the physical USB device, and the VMM will not be able to communicate with the physical USB device and support the VM's access to the physical USB device.
U.S. Pat. No. 7,082,598 (the '598 patent), the entire contents of which are incorporated by reference herein, teaches a driver substitution method that can be used to dynamically replace the driver for a particular device with a different driver. In this method, a special process running in the kernel simulates an unplug event for the device followed by a plug-in event. The unplug event invalidates the driver that the OS has loaded and the plug-in event causes the OS to go through the process of loading a new driver for the device. During the process of loading the new driver, the special process running in the kernel intercepts messages that query the device properties that are used by the OS to generate the hardware and instance IDs of the device and modifies the device properties so that the OS is fooled into loading the driver designated by the special process. One limitation of this method is that the special process is configured to intercept messages only from primary devices. As a result, if a primary device has two or more secondary devices, such as in the case of a USB composite device (e.g., a web camera incorporating both video and audio capture devices), the driver substitution cannot be done on an independent basis for each of the secondary devices.
The '598 patent suggests another possible technique for performing driver substitution. This alternative method employs APIs provided by the OS, such as the Microsoft Windows® API function UpdateDriverForPlugAndPlayDevices( ), to change the driver that is mapped to a specific hardware ID in the registry. The shortcoming of this technique, as recognized in the '598 patent, is that the drivers for all devices with the affected hardware ID are changed. For example, if there are three identical USB cameras, C1, C2, and C3, and the VMM wishes to connect only C1 to a virtual computer and replace the C1 camera driver with a generic USB driver, changing the driver for the C1 camera would also change the drivers for the C2 and C3 cameras because they share the same hardware ID.